查看原文
其他

Pipeline支撑运维自动化:Zabbix屏蔽/恢复监控

三页 木讷大叔爱运维 2022-07-13

预计阅读时间4分钟

简述

CI/CD如何支撑运维自动化》讲述了借助Jenkins 通过Pipeline的方式来实现运维自动化的想法,并规划了以下几个原子模块:

  • 操作系统级

  • Java应用级

  • Apollo配置中心级

  • 监控系统级

  • CMDB级

通过Pipeline对以上原子模块进行编排来满足不同场景的需求。为让大家更深入的理解,下面来介绍下系统监控级原子模块中关于Zabbix屏蔽/恢复监控的应用。


本文涉及功能在运维自动化所处的位置如图:


使用场景

Zabbix屏蔽/恢复监控是作为“系统监控级”原子模块的功能扩展,这是我们从日常的版本发布过程中总结出来的,可应用于以下两个场景:


  • 应用例行启停



  • 版本发布



以上两个场景由于都涉及到应用启动的动作而且都是运维人员的例行操作,因此为了避免此类告警引起不必要的恐慌,我们需要在事前和事终引入屏蔽监控/恢复监控的动作。


注意:从以上场景看出,我们并没有做到任何监控项的屏蔽/恢复,而是只在应用层面实现:

  • 应用的监控检查

  • 应用的端口监控

前置条件

为了方便本次内容的总结,我们以Zabbix监控系统为例。


分析:Zabbix系统的监控项广泛分布于各个Zabbix 客户端,如果屏蔽/恢复监控项,需要按应用IP依次查询,不利于管理。


解决方案:我们将应用的监控检查、端口监控都放到某台Zabbix客户端上进行集中管理,而且统一以应用名为前缀


# 1.健康检查vim  http_site.conf#格式:APP_NAME|MONITOR_URL#解释:应用名|健康检查url#标准urlTEST1|10.10.10.1:8080#非标准urlTEST2|10.10.10.1:8080/XXXXX
# 2.端口监控vim port.conf#格式:APP_NAME|IP:PORT#解释:应用名|ip地址:端口TEST1|10.10.10.1:8080TEST2|10.10.10.2:8080


经过一番改造,我们就可以对应用的健康检查、端口健康等进行统一管理,极大程度上方便了我们后续的操作。


友情提示:应用相关改造可参考《CI/CD支撑运维自动化:系统监控级原子模块》,此文还兼顾到后续监控项的自动增加,用于应用首次上线。---"一般人我不告诉他!"


其在扩展共享库中系统监控级原子模块分布如下:



 


场景实现


监控项屏蔽/恢复 的功能涉及到以下几项:

  • APP_NAME    

    在CMDB中通过APP_NAME可获取应用IP;

  • HTTP_URL

    应用的健康检查地址,可自行定义或统一规范;

  • IP_PORT

    应用的端口监控,用于和HTTP_URL互补对应用是否在线进行监控;

    IP通过APP_NAME在CMDB中查询;

    PORT通过在配置文件中进行过滤,用于和IP进行组合;


具体的实现流程如下:



1.扩展共享库模目录结构

shared-library|--resources|--src|--vars   |--cmdb.groovy   |--apllo.groovy   |--java_deploy.groovy   |--zabbix.groovy   |--sftp.groovy

 

2.模块功能实现

vim zabbix。groovy/*时间:2021-11-15用途:1.zabbix 添加监控2.zabbix 监控项屏蔽与恢复*/import groovy.json.JsonSlurperimport groovy.json.JsonSlurperClassic
// 获取监控项itemiddef GetItemid(ITEM_NAME) { try { def data = """{ "jsonrpc": "2.0", "method": "item.get", "params": { "output": ["itemid"], "hostids": "10355", "search": { "name": "$ITEM_NAME" }, "sortfield": "name" },            "auth": "c919301e492b01236673f2274e9ba9db", "id": 1 }""" def response = httpRequest contentType: 'APPLICATION_JSON', httpMode: 'POST', requestBody: data, url: "http://10.164.194.54:8888/api_jsonrpc.php" def JsonSlurperClassic = new JsonSlurperClassic() def content = JsonSlurperClassic.parseText(response.content) println('Response: '+response.content) return content.result } catch(Exception e) { println("获取监控项itemid异常: " +e) currentBuild.result = 'FAILURE' throw e } }

// 屏蔽/恢复监控项def UpdateItem(ITEM_NAME, ACTION) { try { itemidlst = GetItemid("$ITEM_NAME") for(item in itemidlst) { itemid = item["itemid"] data = """{ "jsonrpc": "2.0", "method": "item.update", "params": { "itemid": "$itemid", "status": "$ACTION" }, "auth": "c919301e492b03f66673f2274e9ba9db", "id": 1 }"""            def response = httpRequest contentType: 'APPLICATION_JSON', httpMode: 'POST', requestBody: data, url: "http://10.10.10.123/api_jsonrpc.php" def jsonSlurper = new JsonSlurper() def content = jsonSlurper.parseText(response.content) println('Response: '+response.content) } } catch(Exception e) { println("屏蔽/恢复告警异常: " +e) currentBuild.result = 'FAILURE' throw e } }

由于是在集中管理机上屏蔽/恢复监控项,在此我们省略了获取集中管理机的hostid操作。而是直接通过固定的hostid来查找对应的监控项是否存在,最后执行新增操作。


3.屏蔽/恢复监控流水线

@Library('shared-library')pipeline { agent any options { timestamps() } stages{        stage('屏蔽监控') { when {                expression { ACTION == 'SHEIELD' } } steps { script {                    println('屏蔽监控')                    zabbix.UpdateItem("${ITEM_NAME}", "1") } } }        stage('恢复监控') { when {                expression { ACTION == 'RECOVERY' } } steps { script {                    println('恢复监控') zabbix.UpdateItem("${ITEM_NAME}", "0") } } } }}


4.Jenkins参数化构建




5.被其他流水线复用

build job: 'zabbix_alarm', parameters: [string(name: 'ITEM_NAME', value: "${HOST}"), string(name: 'ACTION', value: "SHELD")


总结

屏蔽/恢复告警 只作为系统监控级模块的原子操作,我们可以灵活地将其复用到其他流水线中,很好的满足了我们对不同场景的需求。




Python+Celery实现基于Fastnetmon异常流量清洗

Pipeline支撑运维自动化:sftp原子模块

后话:PipeLine支撑运维自动化

Apollo:分布式配置管理中心

CI/CD支撑运维自动化:系统监控级原子模块

运维思索:自动化运维体系如何入手?

事件推送网关: “让基础设施建设动起来”







札记:对的那条路,往往不是最好走的!

喜欢这篇文章,记得点赞+在看哦~


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存